Bo Wang
Sr. Analyst, Stats Programming, Biogen
China %>%
Iowa (Maths/French/Linguistics) %>%
Rhode Island (Biostats ScM) %>%
Boston (since June 2019)
Motivating example: a story
My solution to the problems
Demo (fingers crossed)
Lessons learned
SC is a medical director. They have a very busy schedule but they think it's important to have first hand understanding of the biomarker data collected from ongoing trials, which could point to new research questions and even become evidence submitted to regulatory agencies. So they asked for tables and figures for every cohort/subgroup/pair of contrasts etc.
GZ is a biostatistician. At any given time, they work on at least 10 projects from 5 studies on 3 different compounds. They received the ad hoc table and figure requests, and did some (hopefully) reproducible exploratory analyses. Then they spent multiple hours on the phone/exchanged 50+ emails with SC, trying to come up with clear, succint, non-ambiguous table/figure specifications.
EM is a programmer. They received the specifications from GZ and everything looked fairly doable: join and reshape some datasets, create some filters, scatter plots, spaghetti plots, so they promised to get it done by the end of the week.
…
EM finished the requests on Friday and was ready for the weekend. Suddenly they got a ping from GZ, the biostatistician: “Can you make a small change to the scatter plot? Can you create plots for patients in group A who have type X and are at least 1 year, 6 month, and 3 months old when they started the trial?”
EM finished the modified requests on Monday and sent the 128 plots to GZ and SC for review. Two weeks later, SC, the medical director, came back with 3 plots that turned out to be useful, and asked for changes in plot titles, point sizes, and colors for group B.
Repeat the above process for 2-5 times.
Problem: Functions with no programming background and/or other priorities need an easy way to explore data and reach a consensus of what table/figures should be produced and reduce back-and-forth communication.
Shiny: build interactive web application using R
Easy to start, challenging to reach advanced level
Enthusiam from clients:
Shiny programmer is a new role
A Shiny module is a piece of a Shiny app. It can’t be directly run, as a Shiny app can. Instead, it is included as part of a larger app (or as part of a larger Shiny module–they are composable) …
Once created, a Shiny module can be easily reused – whether across different apps, or multiple … Modules can even be bundled into R packages and used by other Shiny authors. Other Shiny modules will be created that have no potential for reuse, by simply breaking up a complicated Shiny app into separate modules that can each be reasoned about independently.
– Joe Cheng, author of Shiny package
Not necessarilty. Suitable Shiny module features:
Single/few input, single/few output
Does not intertwine with base Shiny structure
Single, confined purpose
p(erfect) <-
Shiny Modules +
code snippet +
R functions +
.rds +
package/extensions